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ABSTRACT 


The  objective  of  this  thesis  is  to  develop  a  new  calibration  system  for  analog  and 
smart  digital  pressure  sensors,  operable  by  only  one  person,  and  capable  of  calibrating  lo¬ 
cal  and  remote  sensors  connected  via  RS232  cables,  Bluetooth  or  an  802.11b  wireless 
LAN. 

It  is  proposed  that  the  operator  uses  a  portable  calibration  standard  and  a  tablet  PC 
to  conduct  the  sensor  calibration.  In  order  to  handle  local  sensors  directly  connected  to 
the  tablet  PC  and  remote  sensors  connected  to  the  tablet  PC  via  a  network  capable  appli¬ 
cation  processor  (NCAP),  a  dual  module  application  is  proposed  and  developed  using 
Lab  VIEW.  The  application  has  a  Master  Module  and  a  Slave  Module.  Both  modules  are 
able  to  connect  to  multiple  digital  sensors  at  the  same  time.  The  Master  Module  was  de¬ 
signed  to  run  on  the  operator’s  tablet  PC  offering  an  easy-to-use  graphical  user  interface 
(GUI)  that  allows  the  monitoring  or  calibration  of  any  connected  sensors.  The  Slave 
Module  was  designed  to  run  on  any  networked  PC,  including  the  operator’s  tablet  and  an 
NCAP.  A  dedicated  Virtual  Instrument  (VI)  was  designed  for  an  iterative  calibration 
process  based  on  a  least  squares  fitting  method.  This  VI  automatically  computes  the 
calibration  constants  that  minimize  the  measurements  errors,  and  writes  the  calibration 
constants  to  the  sensor’s  RAM  or  EEPROM. 

A  prototype  shipboard  sensor  test  bed  was  constructed  in  the  laboratory,  which 
consists  of  a  Honeywell  PPT  digital  pressure  sensor,  an  Omega  analog  pressure  sensor, 
and  other  802.11b  and  Bluetooth  wireless  LAN  components.  The  newly  developed  cali¬ 
bration  system  was  successfully  demonstrated. 
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EXECUTIVE  SUMMARY 

The  objective  of  this  thesis  is  to  develop  a  new  calibration  system  for  analog  and 
smart  digital  sensors,  which  does  not  requires  more  than  one  person  to  fully  operate  and 
is  capable  of  calibrating  local  and  remote  sensors  connected  via  RS232  cables,  Bluetooth 
or  802.1  lb  wireless  LAN. 

In  order  to  handle  remote  sensors  connected  to  shipboard  Network  Capable  Ap¬ 
plication  Processors  (NCAPs)  as  well  as  local  sensors  directly  connected  to  the  operator’s 
computer,  a  dual  module  application  is  proposed  and  developed  using  Lab  VIEW  6.0.  The 
application  has  a  Master  Module  and  a  Slave  Module  that  can  run  in  the  same  or  different 
machines  exchanging  information  used  by  the  monitoring  and  calibration  processes.  As 
far  as  communication  and  interface  are  concerned,  this  application  equally  treats  sensors 
permanently  installed  on  ships  for  measurement  purposes  and  calibration  standards  used 
to  calibrate  other  sensors.  Calibration  standards  are  usually  connected  to  the  application 
as  local  sensors. 

This  dual  module  application  was  designed  for  the  typical  situation  where  an  op¬ 
erator  goes  to  the  calibration  site  with  a  laptop  or  a  tablet  PC  and  locates  the  sensors 
scheduled  for  calibration  already  connected  to  an  NCAP.  If  the  NCAP  is  running  the 
Slave  Module,  the  operator  can  wirelessly  control  all  the  sensors  already  connected  and 
additionally  connect  other  sensors  to  the  laptop  or  tablet  PC,  e.g.,  a  calibration  standard. 
Hence,  the  shipboard  sensors  do  not  need  to  be  disconnected  from  the  NCAP  to  be  cali¬ 
brated. 

Both  Master  Module  and  Slave  Module  are  able  to  connect  and  handle  an  unlim¬ 
ited  number  of  digital  sensors.  The  Master  Module  was  designed  to  run  on  the  operator’s 
laptop  or  tablet  PC  offering  an  easy-to-use  GUI  that  allows  the  monitoring  or  calibration 
of  any  connected  sensors.  The  Slave  Module  was  designed  to  run  on  any  machine  con¬ 
nected  to  the  WLAN,  including  the  operator’s  laptop.  A  dedicated  VI  was  designed  for  an 
iterative  calibration  process  based  on  a  least  squares  fitting  method  and  is  able  to  auto¬ 
matically  compute  the  calibration  constants  that  minimize  the  measurements  errors 
through  the  sensor  full  scale.  The  VI  is  also  able  to  write  the  calibration  constants  to  the 
sensor’s  RAM  or  EEPROM. 

xvii 


A  prototype  shipboard  sensor  test  bed  was  constructed  in  the  laboratory,  which 
consists  of  a  Honeywell  PPT  digital  pressure  sensor,  an  Omega  analog  pressure  sensor, 
and  other  802.11b  and  Bluetooth  wireless  LAN  components.  The  newly  developed  cali¬ 
bration  system  was  successfully  demonstrated  to  NAVSEA-Corona  and  NAVSEA- 
Philadelphia  representatives.  A  lighter  version  was  developed  to  streamline  the  current 
shipboard  calibration  procedures  for  analog  sensors,  reducing  the  time  and  personnel  re¬ 
quired  for  periodical  calibration  tasks.  The  application  is  scheduled  to  be  tested  and 
evaluated  in  the  Land-Based  Testing  Facility  (LBTF)  at  NAVSEA-Philadelphia. 


I. 


INTRODUCTION 


A.  MOTIVATION 

Naval  ships  deploy  many  sensors  to  monitor  shipboard  system  conditions  and  en¬ 
vironmental  conditions.  In  order  to  reduce  the  requirement  for  shipboard  manning,  many 
more  sensors  are  required  for  shipboard  monitoring.  Current  DDG  ships  have  approxi¬ 
mately  3,742  hull,  mechanical,  and  electrical  (HM&E)  sensors  [Ref.  1].  The  number  of 
sensors  required  for  a  next  generation  destroyer,  DD21,  is  expected  to  be  in  the  range  of 
200,000  [Ref.  2], 

The  reliable  operation  and  readiness  of  ships  depend  on  the  accuracy  of  sensor 
data.  To  ensure  accurate  readings  from  sensors  over  long  periods  of  time,  most  sensors 
need  to  be  calibrated  on  a  regular  basis.  The  current  calibration  process  is  mostly  manual, 
time  consuming,  and  labor  intensive  [Ref.  1],  To  meet  the  challenge  of  reducing  crew 
size  and  significantly  deploying  more  sensors  in  the  future,  there  is  a  clear  need  for  de¬ 
veloping  new,  automated  calibration  processes  and  standards. 

While  mechanical  gages  and  analog  sensors  prevail  on  today’s  ships,  advanced 
sensors  such  as  IEEE  1451  smart  sensors  and  wireless  sensors  are  expected  to  be  installed 
on  future  ships.  For  the  most  part,  calibration  processes  for  smart  sensors  have  not  been 
established.  Conventional  analog  sensors  simply  provide  a  voltage  or  current  output  pro¬ 
portional  to  pressure,  temperature,  or  other  physical  parameters  to  be  measured.  Calibra¬ 
tion  constants  are  stored  elsewhere  outside  of  sensors,  e.g.,  at  the  Integrated  Condition 
Assessment  System  (ICAS).  In  addition  to  providing  measurement  readings,  smart  sen¬ 
sors  have  other  features,  including  the  capability  of  storing  calibration  constants  within 
sensors  themselves.  Honeywell  PPT  (Precision  Pressure  Transducer)  is  an  example  of 
smart  sensors  [Ref.  3],  It  provides  pressure  measurements  in  both  analog  and  digital 
forms  and  has  several  programmable  features  such  as  selectable  pressure  units,  program¬ 
mable  integration  time,  automatic  read  rate  adjusting,  network  traffic  reduction,  address¬ 
able  network,  adjustable  calibration  constants,  retaining  new  configurations  in  RAM  or 
EEPROM,  and  others. 
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B.  OBJECTIVE  OF  THESIS  RESEARCH 

The  objective  of  this  thesis  was  to  develop  a  closed-loop  calibration  system  for 
smart  digital  sensors.  The  calibration  system  provides  flexibility  for  calibrating  sensors 
with  different  types  of  connection  configurations,  including  local  sensors,  remote  sensors, 
sensors  connected  with  RS232  cables,  sensors  with  Bluetooth  wireless  connections,  and 
sensors  connected  through  network  ports.  The  calibration  system  is  backward  compatible 
to  calibrate  analog  sensors  as  well. 

C.  DESCRIPTION  OF  CHAPTERS  IN  THESIS 

Chapter  I  defines  the  objective  of  this  thesis  by  giving  a  brief  explanation  about 
the  current  use  of  sensors  in  shipboard  systems  and  the  new  tendency  regarding  the  use  of 
digital  sensors.  Chapter  II  details  the  hardware  used  in  this  thesis.  Chapter  III  describes 
the  two  module  approach  proposed  to  solve  the  problem  and  explains  the  software  archi¬ 
tecture.  Chapter  IV  explains  the  Master  Module’s  design  and  its  major  features.  Chapter 
V  explains  the  Slave  Module’s  design  and  its  major  features.  Chapter  VI  presents  a  sim¬ 
plified  calibration  system  focusing  on  the  monitoring  and  calibration  of  shipboard  analog 
sensors.  Chapter  VII  presents  the  conclusions  and  explains  the  accomplishments  of  the 
thesis. 
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II.  HARDWARE  DESCRIPTION 


This  chapter  presents  hardware  components  used  in  this  thesis.  The  equipment 
used  includes  the  WiSER  2400IP  adapter,  the  Honeywell  Precision  Pressure  Transducer 
(PPT),  the  3e-550I  Industrial  Wireless  Input/Output  Node  (W-LION),  the  3eTI  Industrial 
Gateway,  the  3eTI  Bluetooth  Module,  the  laptop  or  tablet  PC,  the  Portable  Pressure  Cali¬ 
brator  (PPC),  the  digital  sensor  SiPC6  and  the  pump. 

A.  THE  WISER  2400IP  ADAPTER  [AFTER  REF.  4] 

The  WiSER  2400IP  is  an  802.1  lb  compliant,  or  WiFi,  radio  with  an  RS232  serial 
interface.  See  Figure  1. 


Figure  1  WISER  2400IP  Adapter  [From  Ref.  4], 


Figure  2  illustrates  the  WiSER  2400IP  dataflow  when  transmitting  and  receiving 
data  to  and  from  the  wireless  network. 

When  transmitting  to  the  network,  the  WiSER  2400IP  radio  takes  serial  data  from 
the  equipment  or  computing  device  connected  via  its  RS232  port,  converts  the  serial  data 
into  TCP/UDP  data  packets,  and  transmits  these  packets  with  the  RF  modulation  that  is 
compliant  with  the  specifications  of  the  802.1  lb  physical  layer. 
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When  receiving  data  from  the  wireless  network,  the  radio  demodulates  the  RF 
signal,  removes  the  Ethernet  headers,  unpacks  the  packet  and  delivers  the  data  byte-by- 
byte  to  the  destination  equipment/device  through  the  RS232  serial  port. 


WiSER  adapter 


Figure  2  WiSER  2400IP  Adapter’s  Dataflow. 


Each  WiSER  2400IP  radio  acts  as  a  “Station”  and  operates  in  either  infrastructure 
or  ad-hoc  mode  in  accordance  with  the  802.11  standards.  As  such,  this  radio  enables 
RS232-interfaced  devices  to  participate  in  a  wireless  Ethernet  network.  In  this  capacity, 
the  radio,  in  addition  to  eliminating  the  RS232  cables,  functions  as  a  media  converter  for 
RS232-interfaced  equipment  and  IP -based  computing-devices. 


The  radio  is  fully  self-contained  in  performing  the  conversion  between  serial  data 
and  wireless  Ethernet  packets.  That  is,  no  device  driver  needs  to  be  installed  on  the  host¬ 
ing  equipment  or  computing  device  to  which  the  radio  is  connected.  The  True  Plug  and 
Play  feature,  therefore,  is  achieved  with  any  equipment  or  computing  devices  with  a 
RS232  port.  This  also  means  the  radio  can  be  used  on  equipment  and/or  computing- 
devices  with  any  operating  system.  This  is  particularly  useful  for  instruments/equipment 
where  the  use  of  a  RS232  interface  is  utilized. 

1.  Main  Specifications  of  the  WiSER  2400IP  Adapter  [Ref.  4] 


Standard: 

Host  Interface: 
Frequency: 

Link  Distance: 
Data  Encryption: 


802.11b 

RS232 

2.4  GHz  -  2.495  GHz 

-1200  ft  in  open  space 

Support  the  standard  64-bit  and  128-bit  WEP 
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•  Network  Security:  MAC-address-based  access  control 

2.  Use  in  Thesis 

In  this  thesis,  the  WiSER  2400IP  will  be  used  to  connect  smart  digital  sensors  to 
the  wireless  Ethernet  network  in  accordance  with  the  802.11b  standards.  The  application 
shall  allow  the  establishment  of  communication  channels  using  TCP  or  UDP  protocols 
between  each  WiSER  2400IP  and  the  operator’s  laptop/tablet  PC.  Additionally,  when  the 
application  is  running  in  a  dual  machine  configuration,  the  WiSER  2400IP  can  also  be 
connected  directly  to  the  NCAP  (see  Chapter  III). 

The  WiSER  2400IP  adapter  makes  it  possible  to  eliminate  the  RS232  cables,  to 
surpass  the  limitation  of  the  number  of  serial  ports  per  machine,  and  to  pass  over  the 
NCAP  itself  because  the  smart  sensors’  information  can  be  directly  delivered  to  the  client 
application  (ICAS). 

B.  HONEYWELL  PRECISION  PRESSURE  TRANSDUCER  (PPT) 

The  Honeywell  precision  pressure  transducer  (PPT)  is  a  “smart  sensor”  that  com¬ 
bines  silicon  sensor  technology  with  microprocessor-based  signal  conditioning. 

The  heart  of  this  digital  sensor  is  a  silicon  piezoresistive  transducer  which  con¬ 
tains  both  pressure  and  temperature-sensitive  elements.  Digital  signals  representing  tem¬ 
perature  and  pressure  are  processed  by  a  microprocessor  to  produce  fully  temperature 
compensated  and  calibrated  pressure  readings  over  the  entire  -40  to  85  °C  (-40  to  185 
°F)  temperature  range. 

The  user  is  not  allowed  to  modify  the  factory  calibration  major  settings.  However, 
small  adjustments  (±0.6%FS  in  0.005%  increments)  can  be  made  to  the  pressure  transfer 
curve  by  modifying  the  PPT’s  full  scale  slope  and  offset. 

The  factory  calibration,  together  with  the  user’s  adjustments  allows,  in  the  major¬ 
ity  of  the  cases,  the  perfect  calibration  of  the  sensor.  This  feature  is  explored  to  imple¬ 
ment  the  closed-loop  calibration  system  as  described  in  Chapter  IV. 

To  allow  the  user  to  retrieve  and  store  the  full  scale  slope  and  offset  values,  the 
Honeywell  PPT  has  specific  commands.  Additionally,  it  offers  many  others  commands 
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used  to  select  the  type  of  measurement  (pressure,  temperature  in  °F,  temperature  in  °C), 
units  of  pressure,  output  mode,  read  out  resolution,  sample  rates,  baud  rates  and  other 
choices. 

There  are  also  commands  to  set  the  PPT  either  to  a  temporary  configuration,  until 
the  PPT  is  powered  down,  or  to  a  permanent  configuration  if  stored  in  the  internal 


EEPROM. 

applied. 

1. 

In  this  case,  the  stored  settings  are  automatically  loaded  each  time  power  is 

Main  Characteristics  [After  Ref.  3] 

• 

Digital  Accuracy  (from  -40°  to  185°  F): 

±0.05  %  FS  Typical 

• 

Analog  Accuracy  (from  -40°  to  185°  F): 

±0.06  %  FS  Typical 

• 

Temperature  Accuracy  (from  -40°  to  185°  F): 

±1°C  (at  sensing  ele¬ 
ment) 

• 

Operating  Temperature  Range: 

-40°  to  185°F 

• 

Sample  rate: 

8.33  ms  to  51.2  min 

• 

Digital  Resolution: 

Up  to  0.0011  %  FS 

• 

Analog  Resolution: 

1.22  mV  Steps  (12  bits) 

• 

Response  Delay: 

1  ms,  maximum  17  ms 

• 

Long  term  stability: 

0.02  %  FS  max  per  yr. 

• 

Digital  Output: 

RS-232 

• 

Analog  Output: 

0  to  5  V 

• 

2. 

Baud  rate: 

Use  in  Thesis 

1200,  2400,  4800,  9600, 
14400,  19200,  28800. 

This  thesis  uses  the  Honeywell  PPT  digital  sensor  as  the  main  target  sensor  for  the 
closed-loop  calibration  process.  Although  other  types  of  sensors  can  be  used  in  the  digital 
calibration  process,  the  concepts  presented  here  can  be  easily  extended  to  other  digital 
sensors. 

The  Honeywell  PPT  is  used  in  all  different  manners  provided  by  the  application, 
connected  via  an  802.11b  wireless  LAN  attached  to  a  WiSER  2400IP  adapter,  Bluetooth 
or  RS232  cables. 
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Even  if  the  application  is  in  dual  or  single  machine  configuration,  the  sensor  can 
be  connected  to  either  a  Master  or  Slave  Module  to  be  calibrated,  monitored  or  used  as  a 
calibration  standard. 

Hence,  the  Honeywell  PPT  is  used  not  only  to  prove  that  the  application  is  capa¬ 
ble  of  performing  the  calibration  of  digital  sensors,  but  also  to  explore  the  application’s 
flexibility  and  monitoring  capabilities. 

During  the  calibration  process,  if  it  is  used  as  the  target  sensor,  another  sensor  is 
required  as  the  calibration  standard.  On  the  other  hand,  if  it  is  chosen  as  the  calibration 
standard,  the  user  can  benefit  from  its  high  accuracy  to  calibrate  any  other  locally  or  re¬ 
motely  connected  sensors. 
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Figure  3  The  Honeywell  PPT.  [From  Ref.  3]. 

C.  OTHER  COMPONENTS 

In  addition  to  the  WiSER  adapter  and  the  Honeywell  PPT,  this  thesis  uses  a  num¬ 
ber  of  other  hardware  components.  These  components  were  described  in  detail  in  another 
thesis  [Ref.  5].  A  brief  description  of  these  components  is  provided  below. 
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1.  The  3E-550I  Industrial  Wireless  Input/Output  Node  (W-LION) 

The  (W-LION)  is  a  Network  Capable  Application  Processor  (NCAP)  with  a  com¬ 
pacted  and  ruggedized  case,  suitable  for  working  in  severe  environments.  Currently,  the 
W-LION  has  been  used  in  shipboard  systems  to  run  a  data  acquisition  and  managing  pro¬ 
gram  to  acquire  data,  process  the  raw  data  and  send  the  information  to  a  wireless  access 
point  which  transports  it  to  a  client  application  located  elsewhere  in  the  system  architec¬ 
ture  [Ref.  6], 

2.  3ETI  Industrial  Gateway 

The  3e-521N  is  a  wireless  dual  mode  gateway  [Ref.  7].  Similar  to  the  W-LION,  it 
also  has  a  rugged  water  and  corrosive  proof  encasement  developed  for  harsh  environ¬ 
ments  and  meets  military  standards  for  installation  onboard  United  States  Navy  ships.  It 
can  be  configured  in  either  access  point  mode  to  bridge  wireless  users  to  wired  resources 
or  as  a  gateway  to  provide  additional  firewall  protection  along  with  multiple  broadband 
media  selections.  However,  in  this  thesis,  it  is  used  in  the  access  point  mode  together  with 
a  3COM  3CR856-95  router  to  simulate  a  ship  network. 

3.  3eTI  Bluetooth  Module 

The  3e-250  Bluetooth  to  RS-232  cordless  adapter  is  a  small  portable  serial  port  to 
Bluetooth  converter.  It  converts  the  data  flow  from  a  RS-232  serial  port  connection  to 
Bluetooth  protocol  and  transmits  to  other  Bluetooth  adaptors.  With  this  module,  the 
RS232  devices  (Honeywell  PPT  or  Crystal  PPC)  can  be  wirelessly  connected  to  the  lap¬ 
top  or  tablet  PC  as  long  as  they  have  the  Bluetooth  adaptor. 

4.  Laptop  or  Tablet  PC 

The  laptop/tablet  PC  provides  the  user  interface  to  the  entire  process  running  the 
application’s  Master  Module.  It  also  can  run  the  Slave  Module  when  configured  in  the 
single  machine  mode.  The  operator  can  use  the  laptop/tablet  PC  to  calibrate  any  smart 
sensor  connected  to  the  application  by  choosing  a  calibrator  from  the  sensor  set. 

To  be  able  to  control  the  NCAP  when  using  the  dual  machine  configuration,  the 
laptop/tablet  PC  also  contains  a  program  called  vncviewer.exe.  This  program  enables  an 
operator  to  view  and  control  the  desktop  of  the  NCAP  from  the  laptop/tablet  PC. 
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5.  The  Portable  Pressure  Calibrator  (PPC),  the  Digital  Sensor  SiPC6 
and  the  Pump 

The  portable  pressure  calibrator  (PPC)  [Ref.  8],  manufactured  by  Crystal  Engi¬ 
neering  Corporation,  and  the  digital  sensor  SiPC6,  made  by  SI  Pressure  Instruments  Ltd. 
[Ref.  9],  are  also  used  in  this  thesis  for  monitoring  and  calibration  purposes.  As  with  the 
Honeywell  PPT,  these  sensors  can  also  be  either  local  or  remotely  connected  via  Blue¬ 
tooth,  WiSER  2400IP  or  RS232  cable. 

During  the  calibration  process,  a  lightweight  handheld  pump  is  used  to  provide 
the  desired  pressure  through  a  pneumatic  or  hydraulic  medium.  The  maximum  pressures 
that  the  pump  can  produce  are  600  psi  for  a  pneumatic  medium  or  10,000  psi  for  a  hy¬ 
draulic  medium  [Ref.  8], 

D.  SUMMARY 

In  this  chapter,  all  the  hardware  components  used  in  this  thesis  were  presented. 
The  equipment  includes  the  NCAP,  Gateway,  Bluetooth-to-RS-232  adaptor,  laptop/tablet 
PC,  digital  sensor  SiPC6,  Honeywell  PPT,  WiSER  2400IP,  Crystal  PPC  and  the  pump. 
The  next  chapter  presents  the  software  architecture. 
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III.  SOFTWARE  ARCHITECTURE 


This  chapter  discusses  the  calibration  problem  and  proposes  a  two  modules  ap¬ 
proach  as  a  flexible  solution  for  a  new  calibration  system.  The  Lab  VIEW  software  is  pre¬ 
sented  as  the  selected  language  and  some  of  its  features  are  discussed.  The  DataSocket 
interface  is  also  introduced  and  an  initial  depiction  of  the  connection  process  is  offered. 

A.  PROBLEM  STATEMENT 

Mechanical  gauges  and  analog  sensors  are  widely  used  in  shipboard  systems  to¬ 
day.  In  order  to  preserve  reliability,  all  sensors  are  required  to  be  periodically  calibrated. 
However,  the  current  calibration  process  for  analog  remote  display  sensors  is  slow,  labor 
intensive  and  requires  a  team  of  service  members  to  perform  the  task. 

The  need  for  new  calibration  methods  is  clear.  It  is  more  evident  from  the  fact  that 
new  generation  ships  are  expected  to  have  the  number  of  sensors  drastically  increased, 
with  smart  and  wireless  sensors  assuming  a  major  role  in  the  new  systems.  Furthermore, 
the  challenge  to  reduce  the  crew  size  reinforces  the  necessity  of  streamlined  calibration 
methods. 

The  goal  of  this  thesis  was  to  develop  a  new  closed-loop  calibration  system  for 
digital  smart  sensors.  The  system  should  be  designed  to  support  digital  sensors  installed 
in  wireless  network  based  shipboard  systems  which  are  likely  to  be  used  in  new  genera¬ 
tion  ships.  Figure  4  shows  the  basic  Wireless  Local  Area  Network  (W-LAN)  topology  al¬ 
ready  tested  in  the  U.S.  Navy  [Ref.  1],  In  this  topology,  the  W-LION  (Industrial  Wireless 
Input/Output  Node)  is  used  to  connect  to  the  sensors  and  transmit  the  data  via  an  802.1  lb 
wireless  network. 

The  system  must  be  able  to  control  and  calibrate  local  and  remote  digital  sensors 
connected  via  RS232  cables,  Bluetooth,  or  an  802.1  lb  wireless  LAN.  The  sensors  are  lo¬ 
cally  connected  when  they  are  connected  to  the  operator’s  laptop  or  tablet  PC  and  are  re¬ 
motely  connected  when  they  are  connected  to  the  W-LION  (NCAP). 

In  order  to  reduce  the  personnel  and  time  required  to  conduct  the  sensor  calibra¬ 
tion,  the  system  must  also  allow  the  operator,  without  the  help  of  another  service  mem¬ 
ber,  to  control  and  calibrate  any  connected  sensor  from  the  calibration  site. 
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Figure  4  Basic  Wireless  Local  Area  Network  (W-LAN)  Topology  [From  Ref.  6]. 


B.  PROPOSED  APPROACH 

The  program  developed  in  this  thesis  is  able  to  perform  the  monitoring,  control¬ 
ling  and  calibration  tasks  of  smart  sensors  connected  wirelessly  or  through  a  serial  port. 
In  order  to  control  sensors  connected  via  NCAP  or  via  the  operator’s  laptop/tablet  PC,  the 
application  was  designed  to  have  two  main  modules,  the  Master  Module  and  the  Slave 
Module. 

The  Slave  Module  (SM)  was  designed  to  collect  data  from  sensors  connected 
wirelessly  or  through  the  serial  port  (RS232).  However,  this  module  does  not  have  a  user 
interface  and  cannot  be  directly  controlled.  It  relies  on  the  Master  Module  (MM)  to  re¬ 
ceive  the  user  commands  or  to  display  sensor  data. 

The  Master  Module  plays  a  more  perceptible  role  because  it  controls  the  entire 
monitoring  and  calibration  process.  To  perform  this  role,  the  Master  Module  is  directly 
commanded  by  the  user  and  has  a  Graphic  User  Interface  (GUI)  specifically  designed  for 
this  purpose.  In  addition,  it  also  provides  a  dedicated  two-way  communication  channel  to 
the  Slave  Module. 
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This  dual-module  design  offers  flexibility  to  the  application,  allowing  it  to  be 
used  to  control  and  calibrate  shipboard  sensors  that  have  their  data  wirelessly  sent  to  the 
ship’s  LAN  by  a  NCAP.  With  this  configuration,  each  NCAP  in  the  ship  can  run  the 
Slave  Module  to  gather  data  from  a  large  set  of  smart  sensors  while  the  Master  Module 
may  be  running  on  other  machines  from  which  the  sensors  can  be  controlled  or  cali¬ 
brated.  The  calibration  process,  as  described  in  Chapter  IV,  is  faster  and  more  accurate 
than  the  calibration  process  currently  used  in  the  Navy. 

This  dual-module  design  is  suitable  for  the  topology  depicted  in  Figure  4  and  the 
design  is  not  restricted  to  it.  Actually,  when  the  smart  sensors  are  wirelessly  connected  to 
the  LAN,  the  NCAP  is  not  needed  anymore.  However,  the  application  can  still  be  used  to 
control  and  calibrate  the  sensors  if  both  modules  are  executed  in  the  same  machine  wire¬ 
lessly  connected  to  the  sensor’s  network. 

Figure  5  shows  both  the  single  and  dual  machine  configuration,  illustrating  how 
several  sensors  can  be  wirelessly  connected  to  the  Master  and  Slave  modules.  It  also 
shows  that  the  user  can  only  interact  with  the  Master  Module. 


Si  :  sensors  connected  via  RS232,  Bluetooth  or  802.11b  wireless  LAN 


Figure  5  Master  and  Slave  Modules  in  (Left)  Single  or  (Right)  Dual  Machine  Con¬ 
figuration. 

It  is  important  to  notice  that  each  digital  sensor  connected  to  either  Master  or 
Slave  Module  requires  a  bi-directional  communication  channel  in  order  to  be  able  to  re- 
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ceive  commands  and  send  replies.  Furthermore,  during  the  connection  process,  the  user  is 
required  to  advise  on  the  type  of  sensor  and  connection  to  be  used.  Hence,  the  sensors 
shown  in  Figure  5  can  represent  digital  sensors  connected  via  RS232  cables,  Bluetooth  or 
an  802.1  lb  wireless  LAN  attached  to  a  WiSER  2400IP  adapter. 

To  illustrate  how  the  dual-module  design  can  be  useful,  it  is  helpful  to  consider  a 
shipboard  system  with  several  smart  sensors  measuring  pressure  at  different  points  of  the 
ship  and  sending  the  data  to  a  NCAP.  If  the  NCAP  is  running  the  SM,  the  entire  calibra¬ 
tion  process  discussed  in  Chapter  IV  can  be  done  by  one  person  with  a  tablet  PC  or  a  lap¬ 
top  running  the  application’s  MM. 

C.  USE  OF  LAB  VIEW 

Lab  VIEW  was  selected  for  the  software  development  in  this  thesis.  It  is  a  multi¬ 
platform  and  dataflow  program  language  with  an  intensive  use  of  modularity  and  intui¬ 
tive  diagram  representation.  The  modules  are  called  Virtual  Instruments  (Vis)  and  are 
composed  of  two  windows,  the  Front  Panel  and  the  Block  Diagram.  The  Front  Panel  is 
used  as  the  graphical  user  interface  and  contains  the  controls  (inputs)  and  indicators  (out¬ 
puts)  used  by  the  user.  The  Block  Diagram  window  is  the  place  where  the  code  is  actu¬ 
ally  developed.  It  has  terminals  associated  with  all  the  controls  and  indicators  placed  in 
the  Front  Panel.  During  the  development  of  the  graphical  source  code,  functions  are  cre¬ 
ated  and  wired  to  these  terminals  in  order  to  make  operations  with  data  obtained  from  the 
controls  and  to  present  the  results  through  the  indicators.  Both  windows  are  linked  to¬ 
gether  in  the  same  VI  but  are  assembled  independently,  allowing  the  programmer  to  fo¬ 
cus  either  on  the  user  interface  or  on  the  program  functionality. 

D.  USE  OF  DATASOCKET  AS  THE  COMMUNICATION  CHANNEL 

BETWEEN  MODULES 

National  Instruments  in  its  measurement  suite  provides  the  DataSocket  interface. 
DataSocket  is  a  technology  based  on  the  industry  standard  TCP/IP  that  pulls  together  es¬ 
tablished  communication  technologies  for  measurement  and  automation.  It  avoids  low 
level  programming  details  by  using  a  self-describing  format  to  transfer  data  as  strings, 
scalars,  booleans  or  clusters  on  their  original  format,  eliminating  the  need  for  complicated 
parse  code.  This  high  level  feature  is  used  to  simplify  data  exchange  between  the  Master 

and  Slave  Modules  when  they  are  running  on  the  same  or  on  different  computers. 
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To  establish  the  DataSocket  communication  channel,  one  application  writes  the 
desired  data  to  the  Datasocket  Server  through  the  DataSocket  API.  The  application  that 
needs  the  data  uses  the  same  API  to  retrieve  the  data  from  the  server.  Both  applications 
are  “clients”  from  the  DataSocket  Server  point  of  view.  The  first  one  is  also  called  “pub¬ 
lisher”  and  the  second  one  “subscriber”. 

In  this  thesis,  the  Master  and  Slave  modules  can  act  either  as  publisher  or  sub¬ 
scriber  because  two  channels  were  put  into  effect.  The  first  channel  is  established  just  to 
transfer  data  gathered  from  the  Slave  Module’s  sensors  to  the  Master  Module.  The  sec¬ 
ond  is  a  two-way  command-reply  channel  established  to  allow  the  Master  Module  to  con¬ 
trol  the  Slave  Module’s  sensors  and  receive  a  reply  with  the  desired  information  or  error 
message.  It  is  important  to  consider  that  the  Slave  Module  has  only  these  channels  to  pass 
information  to  the  user.  Hence,  it  is  not  allowed  to  open  a  dialog  box  or  request  any  kind 
of  action  directly  from  the  user. 

For  the  purpose  of  this  thesis,  the  DataSocket  communication  is  restricted  to  a 
Local  Area  Network  (LAN).  However,  communication  could  be  established  over  the 
internet  by  using  DataSocket  to  publish  the  applications’  data  as  shown  in  Figure  6.  In 
this  case,  security  becomes  an  issue  and  should  be  treated  accordingly  by  the  use  of 
DataSocket  access  restrictions  to  administer  security  and  permissions. 
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E.  LOCAL  SENSORS  VS.  REMOTE  SENSORS 

The  application  developed  in  this  thesis  is  able  to  control  and  monitor  a  fair  num¬ 
ber  of  sensors  concurrently.  The  software  design  does  not  impose  a  limit  on  the  number 
of  sensors. 

Typically,  the  person  responsible  for  the  calibration  goes  to  the  calibration  site 
with  a  laptop  or  a  tablet  PC  and  a  calibration  standard.  The  digital  sensors  scheduled  for 
calibration  are  already  remotely  connected  to  the  NCAP,  and  thus  are  available  on  the  W- 
LAN.  In  this  typical  situation,  the  operator  needs  only  to  connect  the  calibration  standard 
locally  either  wired  or  wirelessly  connected  to  the  laptop,  after  the  sensor  and  calibration 
standard  are  physically  connected.  Hence,  the  data  coming  from  all  shipboard  sensors 
remotely  connected  to  the  NCAP  can  be  seen  in  the  operator’s  laptop  and  compared  with 
the  data  coming  from  the  calibration  standard  locally  connected. 

When  the  new  calibration  system  is  applied  to  a  shipboard  system  that  uses  the 
topology  depicted  in  Figure  4,  only  the  calibration  standard  needs  to  be  locally  connected 
to  the  laptop/tablet  PC.  However,  if  the  system  to  be  calibrated  does  not  use  the  NCAP, 
the  application  should  be  in  the  single  machine  configuration,  with  both  Master  and  Slave 
Module  running  on  the  operators  laptop/tablet  PC.  In  this  situation,  the  application  must 
be  able  to  connect  all  the  sensors  locally  via  a  laptop/tablet  PC. 

The  use  of  the  WiSER  2400IP  adapter  is  one  way  to  have  as  many  locally  con¬ 
nected  sensors  as  required.  See  Chapter  II  for  hardware  specifications.  The  flexibility 
provided  by  the  dual-module  design  is  further  increased  by  the  use  of  the  WiSER  2400IP 
because  each  device  can  be  connected  to  either  Master  or  Slave  modules  using  a  TCP  or 
UDP  protocol  with  the  WiSER  2400IP  acting  as  a  server  and  the  application  as  a  client. 

F.  SUMMARY 

In  this  chapter  the  two  modules  approach  is  proposed  as  a  flexible  solution  for  a 
new  calibration  system.  The  Lab  VIEW  software  is  presented  as  the  selected  language  and 
some  of  its  features  are  discussed.  An  introduction  to  the  connection  process  is  also  pre¬ 
sented.  The  next  chapter  explains  how  the  Master  Module  works  and  describes  its  major 
features  and  the  calibration  process. 
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IV.  THE  MASTER  MODULE 


This  chapter  presents  the  major  features  of  the  Master  Module  with  emphasis  on 
the  multithread  characteristics,  the  sensor  connection  process,  the  communication 
mechanism  and  the  calibration  process.  The  computations  required  by  the  calibration 
process  are  provided  in  three  different  ways  with  an  example  showing  the  details  related 
to  each  step. 

A.  INTRODUCTION 

The  Master  Module  (MM)  is  the  part  of  the  application  directly  controlled  by  the 
user  and  has  a  Graphical  User  Interface  (GUI)  especially  designed  to  obtain  the  user  in¬ 
puts  easily  and  present  the  results  to  the  user.  See  Figure  7.  Through  the  MM  front  panel, 
the  user  can  add  a  new  sensor  to  the  monitored  set,  view  a  graphical  history  of  each 
monitored  sensor,  enable  or  disable  the  monitoring  status  of  a  particular  sensor,  execute 
the  calibration  of  a  desired  sensor  against  any  other  sensor  chosen  as  a  calibration  stan¬ 
dard,  remove  sensors  from  the  set,  view  the  current  value  of  each  sensor  numerically  and 
graphically,  change  the  type  of  measurement  for  the  Honeywell  PPT,  or  change  the  sen¬ 
sor  configuration. 

B.  MULTI-THREAD  FEATURES 

When  the  Master  Module  starts,  it  goes  through  an  initialization  stage  and  then 
starts  three  concurrent  threads  that  will  be  kept  alive  until  the  application  is  closed  by  the 
user.  The  first  thread  is  responsible  for  reading  and  plotting  the  measurements  sent  by  the 
Slave  Module,  remotely  if  in  the  dual  machine  configuration,  through  the  DataSocket 
channel.  The  second  thread  is  in  charge  of  the  local  measurements  and  it  requests  the  de¬ 
sired  measurements  to  all  locally  connected  sensors  and  displays  the  replies  graphically 
and  numerically.  The  third  thread  implements  an  event  detection  mechanism.  It  is  neces¬ 
sary  to  identify  the  action  requested  by  the  user  based  on  the  controls  modification. 
Figure  8  shows  the  two  first  threads. 
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Figure  7  Application  Graphical  User  Interface  (Master  Module). 


Figure  8  Threads  to  Gather  and  Display  Data  from  Remote  and  Local  Sensors. 
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The  third  thread  is  also  in  charge  of  the  calibration  and  removal  processes,  re¬ 
sponsible  for  establishing  and  maintaining  connections  with  all  the  local  sensors  (sensors 
connected  to  the  Master  Module)  and  for  establishing  and  maintaining  the  DataSocket 
connection  with  the  Slave  Module  which  is  required  to  send  commands  to  the  remote 
sensors  and  receive  their  replies. 

C.  THE  SENSOR  CONNECTION  PROCESS 

Both  Master  and  Slave  Modules  use  an  array  of  clusters  to  keep  track  of  the  sen¬ 
sors  status.  This  array  of  clusters,  named  “Sensor  Set”,  represents  a  table  of  remotely  and 
locally  connected  sensors.  Each  cluster  comprises  19  fields  used  to  store  the  sensor  status 
as  depicted  in  Figure  9. 

When  the  user  presses  the  “Add”  button  to  append  a  new  sensor  to  the  set,  the 
connection  dialog  box  is  displayed,  requiring  the  minimal  information  for  the  new  sensor. 
To  simplify  the  connection  process,  most  of  the  fields  are  filled  with  the  default  values 
that  can  only  be  modified  through  the  GUI  when  the  sensor  is  already  connected.  Actu¬ 
ally,  the  user  does  not  need  to  see  all  the  sensor  fields.  Some  fields  are  hidden  and  di¬ 
rectly  handled  by  the  application. 

Through  the  connection  dialog  box  the  user  can  define  if  the  sensor  should  be  lo¬ 
cally  or  remotely  connected  or  if  the  connection  is  wired  or  wireless.  In  the  case  of  a 
wireless  connection,  the  user  can  use  either  the  Bluetooth  or  802.11b  standards.  If  the 
sensor  is  attached  to  a  WiSER  adapter,  the  user  can  choose  a  TCP  or  UDP  connection. 
Figure  10  shows  the  appearance  of  the  modal  dialog  box  when  the  user  requests  a  TCP 
connection. 
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flag  to  identify  the  monitored  sensors 

identify  sensor  used  as  calibrator 

select  single  or  continuous  mode 

select  type  of  measurement  (pressure  or  temperature] 

button  to  start  calibration  process 

button  to  change  sensor  configuration 
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Figure  9  Example  of  a  Sensor  Cluster. 


Figure  10  Modal  Dialog  to  Append  a  Sensor  to  Sensor  Set. 
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The  RequestNewSensorlnfo.vi,  whose  diagram  is  depicted  in  Figure  11,  is  the 
sub VI  responsible  for  the  connection  dialog  box.  It  is  a  simple  sub VI  which  has  a  subset 
of  the  sensor  cluster  (the  connection  fields),  containing  only  a  few  fields  with  the  mini¬ 
mal  information  required  to  establish  a  sensor  connection.  When  the  user  chooses  the  de¬ 
sired  channel,  the  sub VI  automatically  enables  the  fields  related  to  that  specific  channel 
and  disables  the  fields  for  the  information  that  does  not  apply  to  the  chosen  channel. 
When  all  the  required  information  is  provided,  the  user  can  click  the  OK  button  to  start 
the  connection  process. 


Figure  11  Diagram  of  RequestNewSensorlnfo.vi. 

When  the  user  confirms  the  connection  request,  the  Master  Module  verifies  if  the 
desired  connection  is  remote  or  local.  If  the  user  requests  a  local  connection,  the  sub  VI 
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ConnectSensor. vi,  shown  in  Figure  12,  is  immediately  called.  Otherwise,  the  request  is 
sent  to  the  Slave  Module  through  an  “addSensor”  command,  with  the  cluster  supplied  by 
the  connection  dialog  box. 


Figure  12  Diagram  of  ConnectSensor. vi. 


The  ConnectSensor. vi  sub VI  has  the  sensor  cluster  and  a  cluster  with  the  connec¬ 
tion  fields  as  inputs.  When  a  TCP  or  UDP  connection  is  requested,  it  takes  the  sensor 
URL  and  the  port  numbers  provided  and  tries  to  establish  the  desired  connection.  After 
the  connection  is  established,  the  reference  number  generated  for  the  TCP  and  UDP  con¬ 
nection  is  stored  in  the  sensor  cluster  which  is  the  main  output  of  the  sub  VI. 

D.  THE  CALIBRATION  PROCESS 
1.  Background 

To  understand  how  the  smart  sensor  is  calibrated,  it  is  helpful  to  consider  a  simple 
scale  conversion  case.  Consider  a  linear  analog  transducer  (Tl)  which  produces  a  voltage 
of  1  Volt  when  the  temperature  is  32°F  and  5  Volts  when  the  temperature  is  212°F.  A 
transfer  curve  (TCI)  from  the  transducer  output  voltage  to  a  Fahrenheit  temperature  can 
be  found  in  the  following  manner: 


V  —  l  _  5-1 

F- 32°  “  212°-32° 


(4.1) 
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which  gives 


F  =  45x  F-13° 


(4.2) 


Now  consider  that  a  second  transducer  (T2)  gives  a  voltage  of  0.7  Volt  when  the 
temperature  is  32°F  and  5.2  Volts  when  the  temperature  is  212°F.  The  transfer  curve 
(TC2)  for  T2  is: 


F-0.7  _  5.2-0. 7 
F- 32°  “  212°-32° 


(4.3) 


which  gives 


F  =  40x  F  +  4°  _ 


(4.4) 


Although  the  transducers  T1  and  T2  have  different  output  values,  the  temperature 
can  be  precisely  determined  if  the  correct  transfer  curve  is  applied.  Both  transfer  curves 
have  the  form y  =  a- x  +  b ,  which  is  a  line  with  slope  a  and  offset  b.  TC 1  has  slope  45  and 
offset  -13°  while  TC2  has  slope  40  and  offset  4°. 

Given  a  set  of  N  distinct  points  (x,-,  yi)  related  by  the  expression  y  =  ax  +  b ,  the 
slope  a  and  offset  b  can  be  determined  if  N  =  2.  If  N>2,  the  system  is  over-determined 
and  it  may  not  be  possible  to  find  a  line  which  contains  all  the  given  points  (x„  yi).  In  this 
case,  the  line  that  best  fits  the  points  is  found.  One  of  the  most  widely  used  techniques  to 
solve  this  problem  is  the  Least  Squares  Fitting  (LSF)  [Ref.  10]. 

The  idea  behind  the  Least  Squares  Fitting  is  to  solve  a  set  of  over-determined  lin¬ 
ear  equations  such  that  the  summation  of  the  squared  deviation  is  minimized. 

The  deviation  e,  is  the  difference  between  the  value  computed  from  the  fitting 
curve  (i.e.,  axi  +b )  and  the  actual  value  yt.  The  slope  a  and  offset  b  that  minimize  the 
least  squares  error  can  be  found  by  differentiating  the  expression 

D(a,  6)  =  f>r 2  =  £(<«, +b-y,f  (4.5) 

(=1  i=l 
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which  yields 


8D(a,b ) 


N 


f  N 


i=l 


5a 

dD{a,b )  ^ 


TV 


55 


or  m  matrix  notation 
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which  can  be  solved  for  a  and  b  as  follows 
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(4.10) 


Example  4.1.1:  To  illustrate  how  the  least  squares  fitting  is  used,  consider  a  trans¬ 
ducer  T3  with  temperature  measurements  as  described  in  Table  1: 


Actual  temperature  (°F) 

30 

60 

90 

120 

150 

180 

Output  voltage  (V) 

0.90 

1.64 

2.30 

2.90 

3.60 

4.31 

Table  1  Temperature  vs.  Output  Voltage  for  Transducer  T3. 
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To  compute  the  slope  and  offset  that  minimize  the  least  squares  error,  Eq.  (4.8)  is 
used  with  the  values  in  Table  2. 


i 

xi 

yt 

i 

0.90 

30.00 

0.81 

27.00 

2 

1.64 

60.00 

2.69 

98.40 

3 

2.30 

90.00 

5.29 

207.00 

4 

2.90 

120.00 

8.41 

348.00 

5 

3.60 

150.00 

12.96 

540.00 

6 

4.31 

180.00 

18.58 

775.80 

Total 

15.65 

630.00 

48.74 

1996.20 

Table  2  Summation  Table  for  Example  4.1.1. 


Equation  (4.8)  becomes 


'48.74 

15.65' 

a 

'1996.2' 

15.65 

6 

_b_ 

_  630 

(4.11) 


which  gives  slope  a  =  44.59  and  offset  b  =  -1 1.31,  and  defines  the  line  depicted  in  Figure 
13.  This  line  maps  the  transducer  output  voltage  to  the  measured  temperature  minimizing 
the  error  relative  to  the  actual  value. 


Transfer  curve  (a=44.59,  b=-1 1 .31 ) 


Output  Voltage 

V _ J 


Figure  1 3  Transfer  Curve  After  Linear  Fitting  in  Example  4.1.1. 
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2.  The  Honeywell  PPT  Calibration  Process 

The  Honeywell  PPT  calibration  process  can  be  easily  understood  with  the  help  of 
Figure  14  which  shows  the  calibration  standard  and  a  simplified  model  for  the  Honeywell 
PPT  digital  sensor.  The  figure  illustrates  the  pressure  readings  from  the  calibration  stan¬ 
dard  yc  and  the  readings  from  the  digital  sensor  ys,  when  both  devices  are  measuring  the 
same  physical  pressure p*. 


The  digital  sensor  comprises  three  blocks: 

•  Block  BT  represents  the  piezoresistive  transducer  which  converts  the 
physical  pressure  p  *  to  an  electric  signal. 

•  Block  BO  represents  the  default  factory  calibration  and  temperature  com¬ 
pensation. 

•  Block  B1  represents  the  compensation  block  in  which  constants  aj  and  bi 
can  be  adjusted  by  the  user. 


Digital  Sensor 


BT 

BO 

Bl 

T 

_  J1/  -TA 

y*  * 

— ► 

1 

70  ./  ^  ) 

- ► 

ys  +*i' 

Transducer 

Factory 

User 

calibration 

compensation 

ys 


►  y= 


Figure  14  Introduction  to  Digital  Sensor  Calibration. 


Similar  to  the  previous  examples,  the  goal  of  this  calibration  problem  is  to  find  a 
slope  a  and  an  offset  b  to  replace  ai  and  bj,  which  minimize  the  least  squares  error  be¬ 
tween  ys  and  yc.  If  yo  were  known,  the  values  ci]  and  bi  would  be  computed  by  applying 
the  Least  Squares  Fitting  (LSF)  method  to  a  set  of  points  (yo ,  yc).  However,  yo  is  not 
available.  The  sensor  only  provides  the  current  slope  ai  and  current  offset  bj.  Hence,  the 
slope  a  and  offset  b  that  minimize  the  least  squares  error  can  be  found  using  three  differ¬ 
ent  approaches  described  below. 
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a.  Canceling  the  Current  Compensation  Block  Prior  to  the  Applica¬ 
tion  of  the  LSF  Method 

Although  the  uncompensated  value  yo  is  not  known,  it  can  be  found  from 
ys  by  canceling  the  compensation  applied  by  block  Bl.  Inverting  ys  =  a,  y0  +ht  yields 


To  = 


y1zh 

a\ 


(4.12) 


Hence,  the  desired  slope  a  and  offset  b  can  be  found  by  just  applying  Eq.  (4.8)  to  a  set  of 
points  (yo,yc). 


a  =  ■ 
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(4.14) 


6.  Applying  the  LSF  to  a  Set  of  Points  (yc,  ys)  to  Obtain  a2  and  b2 
(ys  =  a2yc  +  b2)  in  Order  to  Compute  a  and  b 

In  this  approach,  the  LSF  is  applied  to  a  set  of  points  (yc,  jy)  to  find  a  lin¬ 
ear  relationship  between  the  readings  from  the  calibration  standard  and  the  sensor 
(ys  =  a2yc  +b2).  Then,  the  slope  cb  and  offset  lb,  together  with  the  current  values  of  ai 


and  bi,  are  used  to  calculate  the  desired  slope  a  and  offset  b.  From  Eqs.  (4.9)  and  (4.10), 
a 2  and  /?;  are  computed  as  follows: 

N  N  N 
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The  desired  slope  a  and  offset  b  can  be  found  as  follows: 


ys=aiyo+bi 

ys=a2yc+b 2 


a\  }’o  +  b\  =a2yc+h2. 


(4.17) 


Rearranging  the  expression  to  obtain  yc  as  a  function  of  yo  yields 


a,  bi~b2  7 

Tc=—  To+- - -  =  a  y0+b 


(4.18) 


which  gives 


(4.19) 


b=hzh 


(4.20) 


c.  Applying  the  LSF  to  the  Readings  (ys,  yc)  to  Obtain  as  and  bs 
(yc  =  a3ys  +  b3)  in  Order  to  Compute  a  and  b 

This  approach  is  very  similar  to  the  previous  one,  however,  the  linear  rela¬ 
tionship  is  inverted  (yc  =  a3ys  +  b3 ).  Applying  the  LSF  to  a  set  of  points  (ys,  yc)  yields: 


N  N 
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The  desired  slope  a  and  offset  b  can  be  found  as  follows: 


ys=a,y0  +b, 
yc=a3ys+b3 


yc=a3(a{y0  +b,)  +  b3 


(4.23) 


Rearranging  the  expression  to  obtain  yc  as  a  function  of yo  yields 
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Jc  =  «3fli To  +  aA  +b3  =  a  y0+b 


(4.24) 


which  gives 

a  =  a3ax  (4.25) 

b  =  a3bx  +  b3 .  (4.26) 

Comparing  the  equations  vt  =  a2yc  +  b2  and  yc=a3ys+b3,  it  is  easy  to  show  that 
a3  =  1  / a2  andh3  =  -b2  / a2 . 

The  desired  slope  a  and  offset  b  can  be  calculated  using  one  of  these  three 
approaches  just  discussed.  The  calibration  VI  (Calibration.vi)  uses  the  second  approach 
because  the  application  plots  the  fitting  line  each  time  the  user  acquires  a  new  point  dur¬ 
ing  the  calibration  process.  The  second  approach  is  better  for  this  purpose  because  the 
plot  is  done  with  the  readings  from  the  calibration  standard  over  the  horizontal  axis. 

Having  the  desired  slope  a  and  offset  b,  more  work  is  not  needed  if  the 
digital  sensor  allows  the  replacement  of  ai  and  bi  with  the  new  calibrated  values.  How¬ 
ever,  that  is  not  the  case  for  the  Honeywell  PPT. 

Block  BO  of  the  Honeywell  PPT  does  the  temperature  compensation  with 
high  accuracy.  Hence,  when  the  PPT  needs  to  be  calibrated,  in  general,  the  required  ad¬ 
justment  on  ( aj ,  bi)  is  very  small.  For  this  reason,  the  PPT  allows  only  small  changes  in 
these  constants. 

The  default  value  for  ai  is  1  (one)  and  it  is  allowed  to  have  only  0.6% 
variation  from  0.994  to  1.006.  The  default  value  for  6/  is  0  (zero)  and  it  can  be  adjusted 
only  to  values  in  the  range  from  -0.6%FS  to  +0.6FS  where  FS  is  the  sensor’s  full  scale. 
Furthermore,  a;  and  bi  can  only  be  modified  by  the  addition  of  a  multiple  of  0.00005  or 
0.00005*FS  respectively: 

ax  =l  +  X  -0.00005  (4.27) 

bx  =0  +  Z-  0.00005  -FS  (4.28) 
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where  X  (slope  adjustment)  and  Z  (offset  adjustment)  are  integers  in  the  range 
[-120, +120] .  Hence,  the  transfer  curve  ys  =  ary0  +b]  for  the  Honeywell  PPT  compensa¬ 
tion  block  ( ai ,  bi)  is  better  written  as: 

ys=(l  +  X-  0.00005)  •  y0  +  Z  •  0.00005  •  FS .  (4.29) 

The  Calibration. vi  was  developed  to  perform  the  calibration  of  the  Hon¬ 
eywell  PPT  by  adjusting  the  slope  and  offset  in  Eq.  (4.29).  This  task  is  accomplished  by 
the  use  of  the  commands  X=,  Y=,  Z=,  and  F=  described  below,  available  for  the  Honey¬ 
well  PPT. 

•  The  X=  command  adjusts  the  slope  of  the  pressure  output  curve  for  posi¬ 
tive  pressures.  It  modifies  the  positive  full  scale  slope  of  the  PPT. 

•  The  Y=  command  adjusts  the  negative  full  scale  slope  of  differential 
PPTs. 

•  The  Z=  command  adjusts  the  offset  of  the  pressure  output  curve. 

•  The  range  of  adjustments  for  X=,  Y=,  and  Z=,  commands  is  ±0.6%FS  in 
0.005%  increments. 

•  The  F=  command  can  change  the  full-scale  pressure  span  to  any  value  be¬ 
tween  50%  and  100%  of  the  factory  specified  range. 

The  X=  and  Y=  commands  make  the  slope  adjustment,  and  the  Z=  com¬ 
mand  makes  the  offset  adjustment.  The  plots  on  the  left  and  right  hand  sides  of  Figure  15 
illustrate  the  range  in  which  the  slope  ai  and  the  offset  bi  respectively  are  allowed  to  be 
adjusted. 
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3.  A  Digital  Sensor  Calibration  Example 

To  illustrate  how  the  Calibration. vi  works,  consider  the  following  example. 

Example  4.3.1:  Compute  the  new  slope  and  offset  adjustments  to  compensate  the 
measurements  displayed  in  Table  3  for  a  Honeywell  PPT  which  has  current  slope  and 
offset  adjustments  set  to  Xc  =  120  and  Zc  =  -120.  Consider  a  full  scale  of  300  psi. 


Calibrator 

7.82 

15.95 

24.15 

32.20 

39.87 

Sensor 

5.92 

14.08 

22.36 

30.44 

38.17 

Table  3  Data  for  the  Honeywell  PPT  Calibration  Example  4.3.1. 


Figure  16  shows  the  Front  Panel  of  the  Calibration. vi  after  the  acquisition  of  the 
points  listed  in  Table  3.  The  results  of  the  calibration  computations  are  displayed  in  the 
bottom  right  comer.  The  white  line  shows  the  result  of  the  Least  Squares  Fitting  method 
applied  to  the  measurements.  Note  that  the  white  line  fits  the  points  which  represent  the 
sensor  readings  and  is  below  the  calibration  line. 


Figure  16  Calibration. vi  During  Honeywell  PPT  Calibration  Example  4.3.1 
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a.  Solution  Using  the  First  Approach 
•  Find  the  current  compensation  slope  and  offset  (aj,  bj )  with  FS  =  300psi 
From  Eq.  (4.27):  a,  =  l  +  Xc*  0.00005  =  1 .006 

From  Eq.  (4.28):  6,  =  Zc  *0.00005  *FS  =  -1.8 


•  Find  the  uncompensated  values  yo  from  the  sensor  readings  ys 


Sensor  readings 

0’s) 

5.9200 

14.0800 

22.3600 

30.4400 

38.1700 

(Ts  "  b\  )/ai 

(yo) 

7.6740 

15.7853 

24.0159 

32.0477 

39.7316 

Table  4  Conversion  Table  for  Example  4.3.1  .a 

•  Find  the  desired  slope  a  and  offset  b  by  linearly  fitting  the  points  (yo,  yc) 

The  summations  required  by  Eq.  (4.8)  for  the  linear  fitting  are  listed  in 
Table  5. 


To  Te  To  ToTo 


i 

(*/  ) 

(T) 

U2) 

(  xi  T/ ) 

i 

7.67 

7.82 

58.89 

60.01 

2 

15.79 

15.95 

249.18 

251.78 

3 

24.02 

24.15 

576.76 

579.98 

4 

32.05 

32.20 

1027.06 

1031.94 

5 

39.73 

39.87 

1578.60 

1584.10 

Total 

119.25 

119.99 

3490.49 

3507.81 

Table  5  Summation  Table  for  Example  4.3. 1  .a. 


Equation  (4.8)  becomes 


"3490.49 

119.25" 

a 

"3507.81" 

_  119.25 

5 

_b  _ 

119.99 

(4.30) 


which  yields  slope  a  =  0.9997 ,  and  offset  b  =  0.1553 . 
•  Computing  the  new  slope  and  offset  adjustments 
Xnew  =  round  ((a  -l)/0. 00005)  =  -6 

Znew  =  round (b/ (0.00005  *  FS))  =  10 
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b.  Solution  Using  the  Second  Approach 

Find  the  current  compensation  slope  and  offset  (aj,  bi)  with  FS  =  300psi 
From  Eq.  (4.27):  a,  =  1  +  Xc  *  0.00005  =  1 .006 

From  Eq.  (4.28):  6,  =  Zc  *0.00005  *FS  =  -1.8 


Find  ci2  and  62  by  linearly  fitting  the  measured  values  ( ys  =  a2yc  +  b2 ) 

The  summations  required  by  Eq.  (4.8)  for  the  linear  fitting  are  listed  in 
Table  6. 


y2c  ycys 


i 

U) 

U) 

(*?) 

(  xi  T/ ) 

1 

7.82 

5.92 

61.15 

46.29 

2 

15.95 

14.08 

254.40 

224.58 

3 

24.15 

22.36 

583.22 

539.99 

4 

32.20 

30.44 

1036.84 

980.17 

5 

39.87 

38.17 

1589.62 

1521.84 

Total 

119.99 

110.97 

3525.23 

3312.87 

Table  6  Summation  Table  for  Example  4.3.1  .b. 


Equation  (4.8)  becomes 


'3525.23 

119.99' 

a2 

'3312.87' 

119.99 

5 

_b2  _ 

_  110.97  _ 

which  gives  slope  a2  =1.0063 ,  and  offset  b2  =  -1.9563 . 

Finding  new  compensation  slope  and  offset 
From  Eq.  (4.19):  a  =  ax  /  a2  =  0.9997 

From  Eq.  (4.20):  b  =  (bl-b2)I  a2  =  0.15532 

Computing  the  new  slope  and  offset  adjustments 
Xnew  =  round  ((a- 1)/0. 00005)  =  -6 


(4.31) 


Znew  =  round (b I ( 0.00005  *  FS))  =  10 


c.  Solution  Using  the  Third  Approach 
•  Find  the  current  compensation  slope  and  offset  (aj,  bj )  with  FS  =  300psi 
From  Eq.  (4.27):  a,  =  1  +  Xc  *  0.00005  =  1 .006 

From  Eq.  (4.28):  6,  =  Zc  *0.00005 *FS  =  -1.8 


•  Find  as  and  bs  by  linearly  fitting  the  measured  values  ( yc  =  a3ys  +  b3 ) 

The  summations  required  by  Eq.  (4.8)  for  the  linear  fitting  are  listed  in 
Table  7. 


Ts  To  y]  T.To 


i 

(*/  ) 

U) 

U2) 

(  xi  T/ ) 

i 

5.92 

7.82 

35.05 

46.29 

2 

14.08 

15.95 

198.25 

224.58 

3 

22.36 

24.15 

499.97 

539.99 

4 

30.44 

32.20 

926.59 

980.17 

5 

38.17 

39.87 

1456.95 

1521.84 

Total 

110.97 

119.99 

3116.80 

3312.87 

Table  7  Summation  Table  for  Example  4.3.1  .c. 


Equation  (4.8)  becomes 


'3312.87 

119.99' 

a3 

'3312.87' 

119.99 

5 

-V 

_  110.97  _ 

(4.32) 


which  gives  slope  a3  =  0.9937 ,  and  offset  b3  =  1.9440. 

•  Finding  new  compensation  slope  and  offset 

From  Eq.  (4.25):  a  =  ax*a3=  0.9997 

From  Eq.  (4.26):  b  =  a2*bl+b3  =0.1553 

•  Computing  the  new  slope  and  offset  adjustments 
Xnew  =  round  {{a- 1)/0.00005)  =  -6 

Znew  =  round (b/ (0. 00005  *  FS))  =  10 
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These  news  adjustments  were  also  computed  by  the  calibration  VI  result¬ 
ing  in  Xnew  =  -7  and  Znew  =  10 ,  as  shown  in  Figure  16.  The  small  difference  in  the  slope 
adjustment  is  due  to  rounding  errors  in  Table  3  and  subsequent  computation. 

Figure  17  shows  the  readings  from  the  sensor  (red  line)  and  the  calibration 
standard  (white  line)  prior  to  the  execution  of  the  calibration  process.  The  difference  be¬ 
tween  the  readings  is  almost  two  psi. 


Figure  17  Sensor  and  Calibration  Standard  before  Calibration. 


The  new  readings  after  the  calibration  process  are  shown  in  Figure  18  with 
an  actual  pressure  of  5.14  psi  and  in  Figure  19  with  an  actual  pressure  of  39.57  psi.  No¬ 
tice  that  in  both  figures  the  lines  overlapped  demonstrating  that  the  calibration  is  effective 
through  the  entire  range  over  which  the  calibration  is  made. 


Figure  1 8  Sensor  and  Calibration  Standard  after  Calibration  when  the  Actual  Pres¬ 
sure  is  5.14  psi. 
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Figure  19  Sensor  and  Calibration  Standard  after  Calibration  when  the  Actual  Pres¬ 
sure  is  39.57  psi. 


E.  MAIN  SUBVIS  OVERVIEW 

The  Master  Module  hierarchy  is  summarized  in  Figure  20.  Since  some  of  the  Vi’s 
used  by  this  application  are  well-known  from  the  LabVIEW  libraries  and  Lab  VIEW  ex¬ 
amples,  they  are  not  discussed  here.  The  main  Vi’s  specifically  designed  and  developed 
for  this  application  are  listed  in  Table  8  and  briefly  discussed  below. 
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VI 

Brief  Discussion 

Calibra 

This  VI  starts  the  Honeywell  PPT  calibration  process  where  the  user  can  con¬ 
tinuously  acquire  pressure  measurements.  During  the  acquisition,  the  VI  does 

the  linear  fitting  of  the  sensor’s  points  with  respect  to  the  calibration  points  (as¬ 
sumed  to  be  the  actual  pressure).  Hence,  considering  the  calibrator  as  a  refer¬ 
ence,  the  sensor’s  accuracy  is  displayed  graphically  and  numerically  in  terms  of 

slope  and  offset.  The  process  also  allows  the  user  to  store  the  computed  correc¬ 
tions  to  the  sensor  RAM  or  EEPROM  at  any  time. 

Pfepply 

This  VI  uses  the  datasocket  command  channel  to  send  commands  to  the  Slave 

Module  and  waits  for  a  reply.  If  an  answer  is  not  received  after  a  time  out  pe¬ 
riod,  an  error  is  generated. 

Kill 

Error 

This  VI  takes  the  error  cluster  and  an  array  of  error  codes  to  be  ignored  and 

gives  an  error  cluster  free  of  the  requested  errors.  It  also  signalizes  the  errors 

found. 

Hew 

Sensor 

RequestNewSensorlnfo.vi  displays  a  modal  dialog  box  where  the  user  can  de¬ 
fine  a  new  sensor  to  be  connected  and  monitored  or  calibrated.  A  cluster  with 

the  user  information  is  given  as  output. 

Con  , 
nect 

Sensor 

This  VI  takes  the  cluster  with  the  user  information,  tries  to  establish  a  connec¬ 
tion  and  gives  the  complete  sensor  cluster  with  the  information  required  for  the 

monitoring  and  calibration  process.  If  the  attempt  to  establish  a  connection  fails, 

an  error  message  is  generated. 

Gather 

values 

[.....] 

This  VI  is  used  in  the  Master  Module  and  Slave  Module  to  gather  the  measure¬ 
ments  of  the  sensors  connected  to  the  respective  module.  It  takes  the  Sensor  Set 

array  and  gives  an  array  of  doubles  comprising  the  values. 

Update 

Sensor 

Set 

This  VI  updates  the  Main  Module  Sensor  Set  with  the  copy  received  from  the 

Slave  Module.  The  Slave  Module  always  replies  with  a  copy  of  its  Sensor  Set 

when  it  receives  a  command  that  causes  a  modification  of  any  of  the  sensors’ 

fields. 
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VI 

Brief  Discussion 

Re  . 
quest 

Info 

This  VI  is  called  by  the  calibration  VI  to  request  information  from  the  sensors. 

It  can  request  the  current  slope,  current  offset  or  even  the  current  measurement. 

Sensor 

This  VI  sends  commands  to  a  sensor  if  the  sensor  is  connected  to  the  module 

from  which  this  VI  is  being  called,  and  updates  the  Sensor  Set  accordingly. 

Get 

Seq 

This  VI  takes  a  sensor  command,  the  sensor  family  and  the  sensor  mode  as  in¬ 
put  and  produces  an  array  of  strings  comprising  the  sensor  language  strings 

needed  to  perform  the  given  command. 

This  VI  takes  the  information  needed  to  identify  a  sensor  in  the  sensor  set,  the 

sensor  set  itself  and  the  command  string.  It  sends  the  command  to  the  actual 

sensor,  reads  the  reply,  parses  the  measurement  and  provides  the  numerical 

value. 

TCP 

LAST 

Match 

This  VI  takes  a  TCP  connection  reference  number,  a  regular  expression  to  iden¬ 
tify  the  substring  to  be  parsed  and  provides  the  last  match  found  in  the  TCP 

buffer. 

UDP 

LAST 

Match 

This  VI  takes  a  UDP  connection  reference  number,  a  regular  expression  to  iden¬ 
tify  the  substring  to  be  parsed  and  provides  the  last  match  found  in  the  UDP 

buffer. 

[SegJ 

Cmds 

This  VI  is  used  by  the  virtual  sensor  VI  to  communicate  to  local  sensors  con¬ 
nected  through  serial  ports. 

Write 

to 

TCP 

This  VI  takes  a  TCP  connection  reference  number  and  a  string  and  sends  the 

string  through  the  TCP  connection. 

Write 

to 

UDP 

This  VI  takes  a  UDP  connection  reference  number  and  a  string  and  sends  the 

string  through  the  UDP  connection. 

Table  8  Summary  of  the  Key  Vi’s  Designed  for  the  Main  Module. 
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F.  COMMUNICATION  THROUGH  THE  COMMAND-REPLY  CHANNEL 

As  stated  previously,  the  application  uses  DataSocket  to  establish  two  different 
communication  channels  between  the  Master  and  Slave  modules.  The  first  channel, 
named  “data  channel”,  has  only  one  direction  and  is  used  to  receive  data  from  remotely 
connected  sensors.  On  the  Slave  Module  side  of  this  channel,  there  is  one  dedicated 
thread  which  continuously  reads  the  remote  sensors’  data,  organizes  the  data  sequentially 
in  one  numerical  array  and  sends  the  array  to  the  Master  Module,  which  may  or  may  not 
receive  the  information.  If  the  data  array  is  not  received,  the  Master  Module  assumes  that 
the  last  reading  is  still  valid.  Hence,  the  “data  channel”  does  not  need  strong  mechanisms 
to  guarantee  data  delivery  because  the  continuous  data  flux  ensures  that  the  lost  informa¬ 
tion  will  be  updated  in  the  next  cycle. 

The  second  channel,  named  “command-reply  channel”,  is  a  two-way  communica¬ 
tion  channel  used  to  transmit  commands  from  the  Master  to  the  Slave  Module  and  replies 
in  the  opposite  direction.  When  the  Master  Module  sends  a  command  to  the  Slave  Mod¬ 
ule,  it  has  to  be  sure  that  the  requested  actions  were  really  carried  out  because  both  mod¬ 
ules  need  to  keep  their  sensor  tables  synchronized.  The  sensor  table  or  sensor  set  holds 
the  status  of  all  connected  sensors  and  should  be  updated  in  both  modules  when  the  user 
changes  the  number  of  connected  sensors  or  the  status  of  a  particular  sensor. 

The  sub VI  CommandReply.vi,  whose  diagram  is  depicted  in  Figure  21,  was  cre¬ 
ated  with  two  main  goals.  The  first  is  to  let  the  Master  Module  detect  if  the  command  was 
received  and  accomplished  and  the  second  is  to  allow  the  Slave  Module  to  return  a  reply 
when  necessary. 

When  the  command  cannot  be  performed,  the  Slave  Module  returns  an  error  mes¬ 
sage.  If  a  reply  is  not  received  during  the  expected  time,  the  sub VI  generates  a  time  out 
error. 
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Is~nds  a  connand  to  SM  I  hiVa'ts  the  reovl 


The  command-reply  channel  is  implemented  using  a  DataSocket  connection  for 
each  direction.  Thus,  the  command-reply  VI  requires  two  URLs  as  input.  URL_A  defines 
the  DataSocket  connection  used  to  write  commands,  while  URL  B  defines  the 
DataSocket  connection  used  to  read  replies. 

The  Slave  Module  is  able  to  understand  19  commands  previously  defined  as  listed 
in  Table  9.  Each  command  has  a  code,  the  number  of  arguments  and  the  type  of  each  ar¬ 
gument.  Since  each  command  can  have  arguments  with  different  data  types,  the  com¬ 
mand-reply  VI  uses  a  variant  type  for  the  argument  input  terminal. 

When  the  Master  Module  sends  a  command  through  the  command-reply  VI,  the 
command  code  (unsigned  integer)  and  the  variant  are  bundled  in  a  cluster  prior  to  the 
transmission.  Hence,  when  the  cluster  reaches  the  destination,  the  Slave  Module  needs  to 
decode  it  to  ascertain  the  original  data  type  of  each  argument. 

After  command  and  arguments  are  decoded,  the  Slave  Module  performs  the  re¬ 
quested  actions  and  always  replies  with  the  same  command  code.  If  the  command  is  a 
query  for  some  information,  the  reply  comprises  the  command  code  and  the  desired  in¬ 
formation.  If  an  error  occurs  during  the  command  evaluation,  the  reply  comprises  the 
command  code  and  an  error  cluster  with  the  error  code  and  respective  message.  If  none  of 
the  two  conditions  above  occurs,  the  reply  comprises  the  command  code  and  an  empty 
variant. 
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Code 

Command 

Argument  type 

Reply’s  data  type 

01 

useContinuousMode 

Unsigned  Integer 

-  0  - 

02 

useSingleMode 

Unsigned  Integer 

-  0  - 

03 

measurePressure 

Unsigned  Integer 

-  0  - 

04 

measureF  ahrenheit 

Unsigned  Integer 

-  0  - 

05 

measureCelsius 

Unsigned  Integer 

-  0  - 

06 

selectT  argetS  ensor 

Unsigned  Integer 

-  0  - 

07 

getSensorMap 

-  0  - 

cluster 

08 

setMonitoredStatus 

Unsigned  Integer 
Boolean 

-  0  - 

09 

getPressurel 

Unsigned  Integer 

double 

10 

getXZ 

Unsigned  Integer 

Array  of  Integers 

11 

setXZ 

Unsigned  Integer 
Array  of  Integers 

-  0  - 

12 

save2EEPROM 

Unsigned  Integer 

-  0  - 

13 

addSensor 

Cluster 

-  0  - 

14 

removeSensor 

Unsigned  Integer 

-  0  - 

15 

selectCalibrator 

Unsigned  Integer 

-  0  - 

16 

getPressure2 

Array  of  UI 

double 

17 

getSlope 

Array  of  UI 

Integer 

18 

getOffset 

Array  of  UI 

Integer 

19 

matchSensors 

Array  of  UI 

Boolean 

Table  9  List  ol 

Slave  Module’s  Commands. 

G.  SUMMARY 

In  this  chapter,  the  major  features  of  the  Master  Module  were  presented  with  em¬ 
phasis  on  the  multithread  characteristics,  the  sensor  connection  process,  the  communica¬ 
tion  mechanism  and  the  calibration  process.  Three  approaches  were  provided  for  the 
computation  of  the  calibration  process  and,  for  each  approach,  an  example  is  given  to 
show  the  details  related  to  every  step.  The  next  chapter  presents  the  Slave  Module. 
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V.  THE  SLAVE  MODULE 


This  chapter  presents  the  Slave  Module  and  gives  a  brief  description  of  its  main 
sub  Vis.  The  emphasis  is  given  to  the  SlaveCore.vi  that  plays  a  central  role  in  the  Slave 
Module. 

A.  INTRODUCTION 

In  contrast  to  the  Master  Module,  the  Slave  Module  (SM)  does  not  have  a  Graphi¬ 
cal  User  Interface  (GUI)  directly  controlled  by  the  user.  However,  the  Slave  Module  per¬ 
forms  an  important  role  when  an  NCAP  is  used  to  gather  the  sensor  data  in  a  shipboard 
system.  With  both  modules,  the  application  can  talk  to  the  NCAP  through  a  DataSocket 
communication  channel.  Hence,  all  the  sensors  connected  to  the  NCAP  through  the  Slave 
Module  can  be  monitored  and  calibrated  in  the  same  manner  discussed  for  the  Master 
Module. 

B.  MULTI-THREAD  FEATURES 

During  the  connection  process,  all  the  sensors  marked  to  be  remotely  connected 
stay  under  the  Slave  Module  control  until  the  sensor  is  removed.  If  the  user  wants  to  con¬ 
trol  the  sensor  from  the  Master  Module,  the  sensor  has  to  be  reconnected.  After  initializa¬ 
tion,  the  Slave  Module  starts  one  thread  to  gather  measurements  from  all  the  sensors 
whose  connections  are  under  SM  control.  Hence,  even  without  the  direct  control  of  those 
sensors,  the  Master  Module  continuously  receives  information  from  them. 

A  second  thread  is  also  started  after  initialization  to  ensure  that  the  SM  is  always 
listening  to  the  commands  sent  by  the  MM.  When  the  SM  receives  a  command,  the 
SMcore.vi  is  called  to  perform  the  required  actions  and  provide  the  MM  with  the  ex¬ 
pected  reply  or  an  error  message. 

The  SM  threads  are  depicted  in  Figure  22  and  the  sub  Vi’s  hierarchy  in  Figure  23. 
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C.  MAIN  SUBVIS  OVERVIEW 

The  Slave  Module  high  levels  sub  Vis  can  be  seen  in  Figure  23,  where  the  Vi’s  hi¬ 
erarchy  is  expanded  two  levels  down.  Some  of  the  sub  Vis  will  not  be  discussed  here  be¬ 
cause  they  were  already  discussed  in  the  previous  chapter  or  are  well-known  from  the 
Lab  VIEW  libraries  and  Lab  VIEW  examples.  The  sub  Vis  exclusively  designed  for  the 
SM  are  briefly  discussed  below. 
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VI 

Brief  Discussion 

SM 

CORE 

This  VI  is  the  main  sub VI  in  the  SM;  it  takes  the  command  sent  by  the  MM,  the 

reply  URL,  the  Sensor  Set  and  an  error  cluster  as  input.  Performs  the  requested 

action,  sends  a  reply  to  the  MM  and  returns  the  updated  Sensor  Set  and  an  error 

cluster  as  output. 

Select 

Fields 

This  VI  is  used  when  the  entire  Sensor  Set  needs  to  be  sent  through  the 

DataSocket  channel.  It  was  developed  to  make  a  copy  of  the  Sensor  Set  exclud¬ 
ing  the  fields  not  supported  by  the  DataSocket  protocol. 

ID  to 
Sensor 

This  VI  takes  a  sensor  ID  and  the  Sensor  Set  and  returns  the  sensor  cluster  and 

its  index. 

Table  10  Summary  of  sub  Vis  Designed  for  the  Slave  Module. 


The  SlaveCore.vi  subVI  depicted  in  Figure  24  is  the  “heart”  of  the  Slave  Module 
and  is  responsible  for  executing  the  actions  required  by  the  commands  received  from  the 
MM. 

The  diagram  in  Figure  24  shows  how  the  “add  sensor”  command  is  implemented. 
It  takes  the  current  Sensor  Set  and  a  cluster  with  the  command  ID  and  a  variant  data. 
When  the  sub VI  is  called,  it  first  identifies  the  command  in  order  to  identify  which  type 
of  data  is  being  transported  inside  the  variant  element. 

In  the  case  of  the  “add  sensor”  command,  the  data  required  to  perform  the  com¬ 
mand  also  depends  on  which  module  the  sensor  is  being  connected.  When  the  sensor  is 
connected  to  the  Master  Module,  the  Slave  Module  receives  a  cluster  with  the  informa¬ 
tion  of  an  already  connected  sensor  and  only  needs  to  update  its  Sensor  Set.  On  the  other 
hand,  if  the  sensor  is  not  yet  connected  and  should  be  connected  to  the  Slave  Module,  the 
cluster  received  contains  the  information  provided  by  the  user  to  establish  the  desired 
connection.  Hence,  it  establishes  a  connection  if  necessary,  updates  the  Sensor  Set,  and 
sends  a  modified  copy  of  the  updated  Sensor  Set,  excluding  elements  not  supported  by 
DataSocket,  as  a  reply  to  the  Master  Module. 
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The  SlaveCore.vi  is  also  able  to  perform  commands  to  switch  the  sensor  mode  to 
single  or  continuous,  to  read  pressure  or  temperature,  to  read  or  write  slope  and  offset 
used  in  the  calibration  process,  to  set  a  sensor  as  a  calibrator,  and  others. 


URL  reppy  | 

SensorSet  1  n 1 
NCAP  Gonnand  1 


“SensorSet  Out 
a  NCAP  end  error 


Figure  24  Slave  Module  Main  sub- VI  (SlaveCore.vi). 


The  sub VI  SelectFields.vi  has  its  diagram  depicted  in  Figure  25.  It  takes  the  Sen¬ 
sor  Set  and  an  error  cluster  as  input  and  returns  a  variant  as  output.  The  variant  will  con¬ 
tain  a  modified  copy  of  the  Sensor  Set  or  the  input  error,  if  an  error  is  detected.  The 
modified  copy  is  necessary  because  the  Sensor  Set  received  as  input  contains  reference 
numbers  to  the  TCP  and  UDP  connection  and  to  the  opened  file.  These  elements  cannot 
be  sent  through  the  DataSocket  channel. 
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Figure  25  Diagram  of  SelectFields.vi. 


The  IDtoIndex.vi  is  a  very  simple  sub VI  used  to  find  a  sensor  in  the  Sensor  Set.  It 
takes  the  sensor  ID  and  uses  the  while  loop  depicted  in  Figure  26  to  find  the  sensor  index. 
It  also  returns  the  matched  sensor  and  a  Boolean  to  indicate  if  the  sensor  was  found. 
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D.  SUMMARY 

In  this  chapter,  the  Slave  Module  threads  were  presented  with  a  brief  description 
of  its  main  sub  Vis.  Emphasis  is  given  to  the  SlaveCore.vi  which  is  the  main  sub  VI.  The 
next  chapter  presents  a  simplified  version  of  the  calibration  system  designed  for  the  cali¬ 
bration  of  analog  sensors. 
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VI.  THE  NEW  CALIBRATION  SYSTEM  FOR  ANALOG 

SENSORS 

This  chapter  presents  a  simplified  calibration  system  focusing  on  the  monitoring 
and  calibration  of  shipboard  analog  sensors.  It  offers  the  same  calibration  capabilities 
discussed  in  the  previous  chapters  by  means  of  a  new  GUI  based  on  the  prototype  devel¬ 
oped  in  [Ref.  5], 

A.  INTRODUCTION 

Although  the  Master  Module  and  Slave  Module  could  be  easily  adapted  to  con¬ 
trol,  monitor  and  calibrate  analog  sensors,  they  were  designed  to  handle  only  digital  sen¬ 
sors.  Rather  than  add  one  more  capability  to  this  application,  the  decision  was  made  to 
create  another  application  that  is  lighter  and  easier  to  use,  which  could  be  tested  and 
evaluated  by  the  Land-Based  Testing  Facility  at  NAVSEA-Philadelphia  with  a  good 
chance  of  being  approved  for  use  onboard  ships  in  the  near  future.  The  Analog.vi  was 
developed  with  this  purpose  in  mind. 

To  handle  analog  sensors,  several  features  provided  by  the  Master  Module  and 
Slave  Module  are  not  required.  The  connection  process,  the  two-way  communication 
channels  established  with  each  sensor,  and  other  features  offered  by  the  dual  module  de¬ 
sign  are  beyond  the  need  of  analog  sensors  and  provide  an  extra  level  of  complexity  not 
required  for  the  calibration  of  analog  sensors  in  current  shipboard  systems. 

B.  THE  MAIN  VI  AND  THE  USER  INTERFACE 

The  prototype  presented  in  [Ref.  5]  is  the  starting  point  for  this  new  calibration 
system  for  analog  sensors. 

The  Analog.vi  has  three  threads  running  on  the  operator’s  laptop/tablet  PC  de¬ 
picted  by  the  three  loops  in  the  block  diagram  of  Figure  27.  The  central  loop  performs  the 
main  thread,  which  is  responsible  for  reading  data  from  three  different  origins:  the  analog 
sensor,  the  calibration  standard  and  the  ICAS.  The  upper  loop  is  responsible  for  the  de¬ 
tection  of  events  generated  by  the  user  and  the  lower  loop  is  responsible  for  starting  the 
calibration  process  when  requested  by  the  user. 
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In  the  main  thread,  the  analog  sensor  data  comes  from  the  NCAP  through  a 
DataSocket  connection  and  is  represented  by  a  voltage  between  1  and  5  Y  which  is  lo¬ 
cally  converted  to  the  pressure  measurement.  The  local  variables  “multiplier”  and  “addi¬ 
tive”  are  used  to  store  the  slope  and  offset  used  to  make  this  conversion. 


The  Crystal  PPC  is  also  used  by  the  Analog.vi  as  the  calibration  standard  and  can 
be  wired  or  wirelessly  connected  to  the  laptop/tablet  PC. 
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The  ICAS  readings  are  provided  only  for  test  and  evaluation  purposes.  It  allows 
the  operator  to  detect  if  the  local  measurement  matches  the  measurements  taken  by  the 
Integrated  Condition  Assessment  System  (ICAS). 

Figure  28  shows  the  application  graphical  user  interface  which  comprises  four 
sub-panels:  the  control  sub-panel  in  the  top  left  position,  the  sensor  sub-panel  in  the  top 
right  position,  the  ICAS  sub-panel  in  the  bottom  left  position,  and  the  calibration  standard 
sub-panel  in  the  bottom  right  position. 


Figure  28  Front  Panel  of  the  Analog.vi. 


The  control  sub-panel  has  textboxes  used  to  provide  the  DataSocket  Server  ad¬ 
dress,  the  path  to  the  calibration  log  file,  and  the  path  to  the  ICAS  file.  The  Calibration.txt 
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file  depicted  in  Figure  29  is  used  to  maintain  a  history  file  of  the  results  generated  by  the 
calibration  sub VI.  The  ICAS  file  depicted  in  Figure  30  is  used,  for  evaluation  purposes, 
as  a  communication  medium  between  this  application  and  the  ICAS  system. 


r  - 

f  Ca  lib  ration -txt  - 

Notepad 

so® 

II  File  Edit 

Format  View  Help 
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■A 

1 8/22/2003 

12:29  PM 

step 

sensor 

cal  i  hrator| 

1) 

0.  908 

0.020 

2) 

11. 943 

10. 390 

3) 

22. 539 

20. 230 

4) 

33. 062 

29. 990 

5) 

43. 218 

39.440 

6) 

53.179 

48. 760 

Si  ope : 

74.512697  Offset: 

—75. 297940 

8/22/2003 

12:34  PM 

step 

sensor 

cal  i  brat  or 

1) 

47. 973 

47.  940 

2) 

0.106 

0.050 

Si  ope : 

74.549146  Offset: 

-75.390969  v 

Figure  29  Log  File  Generated  or  Updated  at  the  End  of  Calibration  Process. 


In  the  top  right  position,  the  sensor  sub-panel  has  a  gauge  used  to  display  the 
readings  from  the  analog  sensor.  The  first  textbox  provides  the  sensor  full  scale  value 
which  is  used  to  compute  the  sensor  absolute  tolerance.  The  local  variables  “multiplier” 
denoted  by  a  and  “additive”  denoted  by  b  are  used  to  convert  the  voltage  read  from  the 
DataSocket  connection  xs  to  the  pressure  value  ys. 

ys=axs+b.  (4.33) 

In  the  bottom  left  position,  the  ICAS  sub-panel  has  a  gauge  to  display  the  read¬ 
ings  from  the  ICAS  system.  For  evaluation  purposes,  the  agreement  was  to  obtain  the 
ICAS  value  through  a  text  file  which  is  updated  by  the  ICAS  system  periodically.  The 
ICAS  updates  the  file  by  appending  a  line  with  several  fields  as  shown  in  Figure  30.  The 
line  has  the  sensor  ID  in  the  first  field,  the  pressure  measurement  (upon  updating)  in  the 
third  field,  and  the  other  fields  are  filled  with  information  related  to  the  sensor.  In  order  to 
find  the  latest  pressure  written  to  the  file  for  a  specific  sensor,  a  sub VI  was  developed  to 
perform  a  backward  file  search  for  the  desired  sensor.  This  subVI  takes  a  sensor  ID,  finds 


52 


the  latest  appended  line  related  to  the  desired  sensor  and  parses  the  pressure  value  stored 
in  the  third  field.  This  value  is  displayed  and  also  compared  to  the  sensor  local  readings 
to  verify  if  they  are  synchronized  by  the  given  tolerance. 
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Figure  30  The  ICAS.txt  File. 


In  the  bottom  right  position,  the  calibration  standard  sub-panel  displays  the  read¬ 
ings  from  the  calibration  standard  (Crystal  PPC).  This  sub-panel  has  a  text  box  where  the 
tolerance  for  the  sensor  readings  can  be  specified  and  a  menu  ring  used  to  define  the  type 
of  connection  used  by  the  calibration  standard,  which  can  be  RS232  cables,  Bluetooth,  or 
an  802.1  lb  wireless  LAN. 

C.  Vis  RUNNING  ON  THE  NCAP 

On  the  NCAP  side,  two  Vis  are  running,  perchs  daql  local.vi  [Ref.  5]  and  Han- 
dleNCAPConsts.vi.  Figure  31  depicts  the  diagram  of  the  first  one  and  is  responsible  for 
sending  the  analog  sensor  data  through  the  DataSocket  “data”  connection.  This  single 
connection  is  used  to  provide  a  DataSocket  communication  channel  from  the  NCAP  to 
the  user’s  laptop/tablet  PC.  Two  others  DataSocket  connections,  named  “command”  and 
“reply”  connections,  are  used  to  implement  a  two-way  communication  channel  to  allow 
the  management  of  the  calibration  constants  in  the  NCAP  configuration  file. 
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Figure  3 1  Diagram  of  perchs_daql_local.vi  [From  Ref.  5], 


Figure  32  depicts  the  HandleNCAPConsts.vi  diagram  which  is  responsible  for  re¬ 
ceiving,  executing  and  replying  read  or  write  commands.  The  read  command  is  sent  when 
the  user  wants  to  load  the  current  slope  and  offset  values  stored  in  the  file.  The  write 
command  is  typically  sent  after  a  calibration  session  when  the  slope  and  offset  that  mini¬ 
mizes  the  Least  Squares  Errors  are  computed  and  the  user  wants  to  update  the  configura¬ 
tion  file. 
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D.  THE  CALIBRATION  PROCESS 

In  order  to  calibrate  analog  sensors,  the  OmegaCalib.vi  was  developed  to  allow 
the  user  to  start  an  iterative  process  with  three  basic  steps: 

•  read  the  directions  displayed  in  the  message  board; 

•  adjust  the  pressure  accordingly;  and 

•  accept  the  measurements  by  clicking  the  OK  button. 

The  three  steps  are  repeated  as  many  times  as  required  by  the  current  calibration 
procedures.  Each  time  a  new  point  is  acquired,  the  sub  Vi’s  Front  Panel  is  appended  with 
a  new  record  comprising  the  calibration  standard  (PPC)  readings,  the  sensor  readings  and 
the  limits  of  the  sensor  tolerated  range.  Additionally,  a  graphical  visualization  of  the 
measured  values  along  with  the  actual  pressure  is  provided.  Figure  33  shows  the  user  in¬ 
terface  used  during  the  calibration  process.  Note  that  the  white  line  is  fitted  to  the  meas¬ 
ured  values  and  is  above  the  line  of  the  actual  pressure  values  (red  line).  This  situation 
indicates  that  the  current  slope  and  offset  are  generating  sensor  readings  greater  than  the 
calibration  standard  readings.  The  Front  Panel  also  shows  the  current  slope  and  offset  and 
the  computed  values  required  to  minimize  the  Least  Squares  Errors. 

The  user  can  locally  validate  or  abort  the  calibration  process  by  pressing  the 
“Done”  or  “Abort”  buttons,  respectively,  at  any  time  during  the  calibration  process. 

Figure  34  depicts  the  Block  Diagram  of  the  OmegaCalib.vi.  It  is  composed  of  an 
initialization  block,  the  main  loop  and  the  final  block.  The  initialization  block  is  used  to 
set  the  controls,  variables  and  indicators  to  initial  values  required  by  the  main  loop.  The 
main  loop  is  the  block  that  interacts  with  the  user  and  performs  the  calibration  process. 
The  final  block  is  responsible  for  generating  the  log  file  depicted  in  Figure  29. 
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Figure  33  User  Interface  for  the  Calibration  Process. 


Figure  34  OmegaCalib.vi  Block  Diagram. 
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Figure  35  illustrates  the  Front  Panel  of  the  Analog.vi  after  the  calibration  process. 
Note  that  the  local  variables  “multiplier”  and  “additive”  were  updated  and  that  the  error 
between  the  sensor  and  calibrator  standard  is  very  small. 


Figure  35  Front  Panel  of  Analog.vi  After  the  Calibration  Process. 


E.  SUMMARY 

In  this  chapter,  a  new  calibration  system  was  designed  to  perform  the  monitoring 
and  calibration  of  analog  sensors  already  used  by  shipboard  systems.  The  GUI  developed 
in  [Ref.  5]  was  taken  as  the  starting  point  to  obtain  a  lighter  version  of  the  new  calibration 
system.  The  next  chapter  presents  the  conclusions  and  explains  the  accomplishments  of 
the  thesis. 
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VII.  CONCLUSIONS 


A.  SUMMARY 

This  thesis  presented  the  design  and  development  of  a  new  closed-loop  calibration 
system  for  shipboard  pressure  sensors.  The  software  of  the  calibration  system  was  im¬ 
plemented  using  Lab  VIEW,  which  is  the  industrial  standard  language  for  measurements 
and  automation.  The  calibration  system  takes  advantage  of  the  latest  wireless  communi¬ 
cation  technologies  including  802.11b  wireless  LAN  and  Bluetooth.  The  version  of  the 
calibration  system  developed  at  the  completion  of  this  thesis  was  operational  and  success¬ 
fully  demonstrated  to  the  project  sponsor. 

The  fundamental  approach  taken  in  this  thesis  was  to  wirelessly  transmit  both  the 
sensor  data  and  calibration  standard  to  a  Tablet  PC.  The  Tablet  PC  compares  pressure 
measurements  from  the  sensor  and  calibration  standard  at  multiple  pressure  points  gener¬ 
ated  by  a  portable  hand  pump.  The  calibration  constants  (slope  and  offset)  are  automati¬ 
cally  computed,  and  downloaded  to  the  smart  sensor  at  the  request  of  the  user. 

The  newly  developed  calibration  system  has  the  following  features: 

•  It  adopts  a  modular  approach  to  software  development,  which  makes  it 
easy  and  flexible  to  use  and  expandable  in  the  future.  The  system  consists 
of  two  main  modules  named  Master  Module  and  Slave  Module.  The  Mas¬ 
ter  Module  always  resides  on  the  Tablet  PC,  providing  a  graphical  user  in¬ 
terface  (GUI)  for  the  user  to  enter  commands  and  view  measurements  and 
other  useful  information.  The  Slave  Module  can  reside  on  the  same  Tablet 
PC,  or  on  a  remote  machine  (e.g.,  on  an  NCAP). 

•  It  is  capable  of  handling  local  sensors  directly  connected  to  the  Tablet  PC 
and  remote  sensors  connected  to  an  NCAP  or  other  networked  computers. 
Sensors  in  this  sense  can  be  a  sensor  to  be  calibrated  or  a  calibration  stan¬ 
dard. 

•  It  is  capable  of  connecting  sensors  using  RS232  cables,  an  802.11b  wire¬ 
less  LAN,  and  Bluetooth. 

•  It  can  be  easily  operated  by  one  person. 

•  It  is  capable  of  calibrating  more  than  one  sensor  at  a  time.  This  feature 
can  be  used  in  a  calibration  facility  where  multiple  pressure  sensors  are 
connected  to  a  single  pressure  source  manifold. 

•  It  automatically  computes  calibration  constants  (slope  and  offset). 
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•  It  is  able  to  retrieve  the  current  calibration  constants,  and  write  the  new 
constants  directly  to  the  smart  digital  sensors. 

•  It  provides  an  effective  Graphical  User  Interface  (GUI)  for  displaying  the 
sensor  readings  and  accepting  user  commands. 

B.  FUTURE  WORK 

Since  the  calibration  system  was  developed  using  a  modular  approach,  it  can  be 
easily  extended  to  accommodate  other  calibration  requirements.  The  calibration  system 
in  the  present  form  was  mainly  developed  for  the  Honeywell  PPT  smart  sensor.  The  pro¬ 
cedures  documented  in  this  thesis  can  be  used  to  develop  calibration  systems  for  other 
digital  sensors. 

The  calibration  system  developed  in  this  thesis  is  currently  a  stand-alone  system. 
One  possible  direction  for  future  work  is  to  integrate  it  with  the  Integrated  Condition  As¬ 
sessment  System  (ICAS). 

The  newly  released  Lab  VIEW  7.0  version  provides  support  for  handheld  devices 
such  as  the  iPAQ  Pocket  PC.  It  is  possible  to  port  the  calibration  system  currently  devel¬ 
oped  for  the  Tablet  PC/Laptop  PC  to  the  Pocket  PC. 
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